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0 scription 

Field of The invention 

[0001 ] The present inv ntion relates to the safe deliv- 
ery of messages between application programs in a 
transaction-oriented data processing network, such that 
no messages are bst and none are delivered more than 
once. 

Background To The Invention 

[0002] It is known for updates to computer system re- 
sources (such as databases or file resources) to be 
made as a coordinated set of changes to two or more 
resources, such that either all of the changes take effect 
or none of them does. In this way, resources are pre- 
vented from being made inconsistent from each other. 
If one of the set of update operations fails then the others 
must also not take effect. A sequence of associated op- 
erations which transforms a consistent state of a recov- 
erable resource into another consistent state (without 
necessarily preserving consistency at all intermediate 
points) is known as a 'unit of work'. Transaction 
processing is the execution of discrete units of work that 
access and update shared data. Logical points of con- 
sistency at which resource changes are synchronised 
within transaction executbn (e.g. at termination) are 
called commit points or syncpoints (see bebw). An ap- 
plication ends a unit of work by declaring a syncpoint, 
or by the application terminating. The characteristic of 
a transaction being accomplished as a whole or not at 
all is known as "atomicity". 

[0003] Atomicity of a transaction is known to be 
achieved by resource updates made within the transac- 
tion being heki in-doubt (uncommitted) until a syncpoint 
is declared at completbn of the transaction. That is, the 
resource updates are only made permanent and visible 
to applications other than the one which performed the 
updates on successful completion. If the transaction 
fails to complete successfully, then all changes that 
have been made to resources during the partial execu- 
tion are removed - the transaction is said to rollback (or 
synonymously to backout). the resources being re- 
stored to the consistent state which existed before the 
transaction began. Any party (e.g. an application or re- 
source manager) with an interest in the unit of work can 
cause a rollback when a syncpoint is declared by indi- 
cating unreadiness to commit. 

[0004] A common problem in the provision of failure- 
tolerant data transmission is how to determine what 
stage has been reached in the transfer of messages that 
were in-doubt (i.e. had not been committed) when a fail- 
ure occurred, to ensure that no messages are lost and 
none are sent more than once. Not all transaction sys- 
tems r member the state of in-doubt messages. 
[0005] The commit procedure is known as a "single- 
phase* procedure if only a singi resourc manager (the 



system softwar which contr Is resourc s) is responsi- 
ble f r coordinating the commltm nt f changes made 
by the transaction. Single phas commit processing is 
efficient in normal forward processing, consisting simply 

s of issuance of a COMMIT peration instruction by an 
application or resource manager and then executkxi of 
the operation by the recipients of the instruction. There 
may be more than one resource manager involved, but 
the coordinator only calls each one once at syncpoint 

10 time to instruct them either to commit or rollback. In the 
vast majority of cases, all resource updates will be com- 
mitted without error or interruption. However, if a prob- 
lem arises (e.g. system or communicatkMi link failure) 
such that not all resource managers are unable to com- 

IS mit, then the resources can end up in an inconsistent 
state with some commits having been completed while 
others have not. The inconsistent resources then re- 
spire resynchronisation. The cost of rebuilding non-crit- 
ical resources following such a problem may be tolera- 

20 bte in view of the efficiency of the single-phase commit 
procedure. 

[0006] In contrast, a two-phase commit procedure is 
often required to protect critical resources from such in- 
consistencies. For example, a financial application to 
2S carry out a funds transfer from one account to anc^her 
account has two basic operations no perform to critical 
resources: the debit of one account and the credit of the 
other It is important to ensure that either both or neither 
of these operations take effect. A two-phase commit 
30 procedure under the control of a syncpoint manager 
consists of the following steps: 

1. During a prepare phase, each participant re- 
source is polled by the syncpoint manager to deter- 

3S mine whether the resource is ready to confirm and 
finalise all changes. Each resource promises to 
commit the resource update if all resources indicate 
readiness (i.e if they successfully complete the pre- 
pare phase); 

40 

2. During a commit phase, the syncpoint manager 
instructs all resources to finalise the updates or to 
back them out if any resource could not complete 
the prepare phase successfully. 

4S 

[0007] The advantage of the additional prepare phase 
is in reducing the likelihood of inconsistencies, but there 
remains a period during processing at which even two- 
phase commit leaves the possibility of inconsistencies 
50 between resources if an error occurs. Also, there is a 
cost which accompanies the two-phase commit's reduc- 
tion in the probability of inconsistencies: since all updat- 
ed resources must be locker to prevent further update 
access for the duration of the unit of work, additional 
55 steps in the commit processing may represent a consid- 
erable reduction in concurrency of resource update 
processing (partcuiarly if many resources are involved). 
If the resources are distributed around a network, two 
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phase commit requires a distributed unit o1 work, which 
introduc s the likeilhood of looks being held for long p • 
riods. and also requir s much more complicated recov- 
ery procedures. Three-phase and other multi-phase 
commit procedures may be impi mented t f urth r r - 
duce the window of time in which a failure can cause 
inconsistencies, but each additional step of preparation 
for commit represents a cost in loss of concurrency. 
[0008] The IBM System Network Architecture SNA 
LU6.2 syncpoint architecture (reference SC31-6608 
Chapter 5.2 'Presentation Servk:es - Sync Point Verbs', 
published by International Business Machines Corpora- 
tion) has been known to coordinate commits between 
two or more protected resources. This architecture ad- 
dressed syncpoint facilities consisting of a syncpoint 
manager which performed both syncpoint and associat- 
ed recovery processing running in a single application 
environment. Several applications could run simultane- 
ously in this environment. The LU6.2 architecture sup- 
ports a syncpoint manager (SPM) which is responsble 
for resource coordination, syncpoint logging and recov- 
ery. 

[0009] According to the SNA LU6.2 architecture, in 
phase one and in phase two, commit procedures are 
executed and the syncpoint manager logs the phase in 
the syncpoint log. Also, the syncpoint manager logs an 
identification of a logical unit of work which is currently 
being processed. Such logging assists the syncpoint 
manager in resource recovery or resynchronisation in 
the event that a problem arises during the two-phase 
commit procedure (e.g. a problem such as failure of a 
communication path or failure in a resource manager). 
If such a problem arises subsequent to entering the two- 
phase commit procedure, the log is read and resource 
recovery processing takes place to bring the resources 
involved in the commit to a consistent state. This two 
phase commit procedure requires kxks to be held 
across different computers using distributed units of 
work. 

Summary Of The Inventbn 

[0010] In a first aspect, the present invention provides 
a method of inter-program communication in a transac- 
tion-oriented data processing network wherein a sender 
program is responsible for sending messages from a 
first node of the network and a receiver program is re- 
sponsible for receiving messages at a second node of 
the network, messages to be transmitted between the 
two nodes being sent from the sender program within a 
first syncpoint-manager-controlled unit of work and be- 
ing received by the receiver program within a second 
syncpoint-manager-controlled unit of work such that the 
sending and receiving operations are held in-doubt (un- 
committed) until resolution of the first and second units 
of work, respectively, characterised in that th first and 
second units of work are logically linked so that commit 
processing at resolution of the units of work comprises 



either 

in response to successful receipt f the messages 
by the receiver program, committing said second 
s unit of work, transmitting to the s nder program a 
positive confirmation of receipt, and in response to 
the positive confirmation committing the first unit of 
work; or 

in response to unsuccessful receipt of the messag- 
10 es. rolling back the second unit of work, transmitting 
to the sender program a negative confirmation of 
receipt, and in response to said negative confirma- 
tion backing out the first unit of work. 

IS [0011] The present inventnn reduces the problem of 
the known single-phase commit procedures of failures 
during commit processing causing inconsistencies be- 
tween resources that then require resynchronisatk>n. 
and also avoids the undesirable increased locking of re- 
^ sources that is a feature of the extra prepare stage in 
the known two-phase commit procedures. 
[0012] Preferably, if the confirmation from the receiv- 
ing program is tost, due to a system or communicatk>n 
link failure, then the first unit of work remains in doubt 
Log records which were written for each get and put op- 
eration performed by the sending and receiving pro- 
grams are then examined to determine which opera- 
tions have been committed at the receiving end thereby 
to determine which operations should be committed and 
30 which should be backed out at the sending end. 

[0013] The present inventbn nnay be implemented in 
a network of computers wherein application programs 
communicate using messaging and queuing and where- 
in a message queue manager program is located at 
3S each computer in the network, the transmission be- 
tween the aforesaid sender and receiver programs be- 
ing transmission between respective queue manager 
programs. The nodes of the network are either message 
queue managers or computer systems on which one or 
40 rnore queue managers are located. Message transmis- 
sion between queue managers involves a first queue 
manager getting an applicatbn-program-originated 
message from a queue and sending the message, and 
a second queue manager receiving the message and 
45 putting it onto a second queue (either for processing by 
a local application program, or for transmission to an- 
other queue manager if neither the first nor the second 
queue manager was the destination queue manager). 
Messaging and queuing is described in the document 
so "IBM Messaging and Queuing Series - technical refer- 
ence " (SC33-0e50-01. 1993), and below in relation to 
an embodiment of the present inventk)n. 
[0014] It is preferred that each message-sending or 
message-receiving unit of work may include a plurality 
ss of messages, and that each confirmation of receipt (or 
receipt and storage, if received messages are put to 
queues) may relate to such a plurality of messages. This 
method of transmitting m ssages in a batch as a unit of 
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work provides a great improvem nt in processing ffi- 
ciency, since th transport connection direction (for- 
wards f r message transmission and backwards for 
confimnation of receipt) is only turned around at th end 
of each batch. This is distinguished from the prior art 
method of sending messages to queues as individual 
units of work and committing after each send operation, 
which risks leaving resources at the sending end in an 
inconsistent state with resources at the receiving end, 
and requires a change of direction of message flow after 
each send and after each confirmation if two phase com* 
mit is used. This batch transmissicn of messages be- 
tween sending and receiving programs, as a stage of 
the transfer of messages between application pro- 
grams, Is also clearly distinguished from batch process- 
ing by an application program, which is well known in 
the art. 

[001 S] The messages which may be transmitted as a 
batch In this way may be logically unrelated and may be 
destined for different application programs (which may 
be served by different queue managers) - the only com- 
mon factor between the messages which is necessary 
for them to be transmitted as a batch between a first and 
a second queue manager is that the second queue man- 
ager is the next queue manager from the first queue 
manager on the way to each message's destination 
queue manager. Prior art methods of message trans- 
mission do not enable batch transmission (where batch 
size is greater then one) of messages which are des- 
tined for different application programs, and so cannot 
benefit from the processing efflctency provided by the 
present invention. For many database systems, commit 
processing is the expensive stage of the processing in 
terms of computing facilities - in particular, disk access 
is expensive as compared with RAM processing - so Im- 
provements to commit processing efficiency are highly 
desirable. 

[001 6] Preferably, the batch has a request to commit 
the batch and to confirm receipt transmitted with it to the 
receiving program, so that commit processing is being 
coordinated by the sending end of the communication. 
A message may be transmitted as a plurality of seg- 
ments if it is too large for the transport connection to 
transfer in one go. Where there is segmentation, the re- 
quest for confirmation will be associated with the last 
segment in the batch. On successful receipt of the batch 
of messages at the receiving end the confirm request is 
acted on by committing the receipt and communicating 
a confirmatbn of the successful receipt. 
[0017] In a second aspect, the present invention pro- 
vides a method of inter-program communication in a 
transaction-oriented data processing network wherein 
a message to be delivered is sent to a queue from a 
sending application program at a first computer and is 
then asynchronously taken from the queue to be proc- 
ess d by a receiving application program, charact rised 
in that: 



each step f s nding a message to a queue or tak- 
ing a message from a queu is carried out under 
th control f a message queue manager program, 
at least one of which is located at each computer in 
s th n twork; 

messages to be delivered to a kx:al application pro- 
gram are put on a local queue serviced by the local 
application program; whereas 
messages to be delivered to remote application pro- 
10 grams on remote computers are put on local trans- 
mission queues for transmission, respectively for 
each transmissk)n queue, to the next message 
queue manager program on the way to the respec- 
tive destination remote message queue manager 
15 programs, wherein all messages put on a particular 
transmission queue, which messages may be des- 
tined for different destination message queue man* 
ager programs, are transmtssable to said next mes- 
sage queue manager as a batch of messages within 
20 a syncpoint-manager-controlled unit of work. 

Description of an Embodiment 

[0018] The present invention will now be described in 
2S more detail with reference to the accompanying draw- 
ings in which: 

Figure 1 is a representation of the data fiek^s mak- 
ing up a message; 
30 Figure 2 is a schematk: representation of two pro- 
grams communicating wKh each other using mes- 
saging and queuing; 

' Figure 3 is a representation of two adjacent compu- 
ter systems and the interrelatk)nships between the 
3S system entities involved in message communk:a- 
tion according to an embodiment of the present in- 
vention; 

Figure 4 is an overview flow diagram of a method 
of message communication between application 
^ programs according to an embodiment of the 
present invention; 

Figure 5 is a representation of the message flows 
between processes during normal forward process- 
ing in a method of communicatbn between applk:a- 
^ tion programs, according to an embodiment of the 
present invention. 

[0019] Message queuing is a message of inter-pro- 
gram communication which albws programs to send 

so and receive application -specific data without having a 
direct connectbn established between them. Before de- 
scribing the detail of a specific implementatbn of the 
present inventbn in a messaging and queuing network, 
it will be helpful to describe the general methodology of 

ss inter-program communication using messaging and 
queuing. 

[0020] A message consists of two parts, application 
data 1 and a message descriptor 2 containing control 
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information 3, as sh wninFigur 1. The application data 
in a message is defined and supplied by the applicati n 
which s nds the message. There ar no constraints on 
the nature of the data in the message (for xample. it 
could consist of one or more of bit strings, character 
strings, binary integers, packed decimal integers, float- 
ing point numbers). Applications view the string of bits 
and bytes that make up a message as consisting of a 
sequence of Items which each have a particular data 
type and meaning. For example, if the message relates 
to a financial transactk^n, the first item 4 may be a four- 
byte unsigned binary integer containing an account 
number and the second item 5 may be a twenty-byte 
character string containing a customer name. This data 
is called the applicatbn data. 

[(}021] In addition to the applk^tion data, a message 
has associated with it some ancillary data. This is infor- 
mation that specifies the properties of the message, and 
is used by the message queuing service to decide how 
the message should be processed. Some of this infor- 
mation must be specified by the application. This ancil- 
lary control information is contained in a data structure 
called the message descriptor 2. 
[0022] A message queue Is a named object in which 
messages accumulate and from which they are later re- 
moved. Each queue belongs to one partk:ular queue 
manager, which is responsible for the maintenance of 
that queue. A queue manager can own many queues, 
but each queue must have a name that is unique within 
the queue manager instance that owns the queue. A 
message queue is not merely a stack: when messages 
are added to a queue, they are added at the end, and 
when messages are taken from a queue, they are nor- 
mally removed from the front (although facilities do exist 
for reading messages in other than a FIFO order - for 
example it may be desirable for messages which require 
a reply to be retrieved as a high priority). 
[0023] The physical representation of a message 
queue depends on the environment, but can be a buffer 
or buffers in main storage, a file or files on disk or other 
permanent storage device, or both of these. However, 
the physk:al management of message queues is entirely 
the responsibility of a queue manager (the system serv- 
ice that provides the message-queuing facilities used by 
applications), and such details are not made apparent 
to the applk;atbn program. Applications can view a mes- 
sage queue simply as a "black box' in which messages 
accumulate. Applications have no access to message 
queues other than through the message queuing calls 
(such as MQGET for taking messages from a queue and 
MQPUT for sending messages to a queue). Applica- 
tions obtain message queuing services by using the 
message-queuing calls to communicate with the queue 
manager that is installed on the same system as the ap- 
plication (i.e the local queue nrtanager). 
[0024] For messag queuing services to be available, 
there must be at least one queue manager on a system. 
More than one queu manager may b required, for ex- 



ample, in order to keep devebpment work s parate 
from production w rk. Each different queu manager in- 
stance is known by its name, which must generally be 
unk^ue within the network of interconnected queue man- 
5 agers so that one queu manager can unambiguously 
kJentify the target queue manager to which any given 
message should be sent. 

[0025] Applications communicate by agreeing to use 
particular named message queues, sending messages 
10 to the specific target queues that the appi cation pro- 
grams have agreed to read from. The location of these 
queues need not be apparent to the applicatbns which 
send the messages; each application interacts only with 
its local queue manager, and it is the network of inter- 
is connected queue managers that is responsible for mov- 
ing the messages to the intended queues. Since cross- 
network communicatk>n sessions are established be- 
tween queue managers rather than between individual 
programs, programs are less vulnerable to network fail- 
ures than in certain other types of inter-program com- 
munication. If a link between processors fails, it is the 
job of the queue managers to recover from the failure. 
ProgranDs on the effected processors are not brought to 
a halt by such an event, and indeed need not be aware 
that ft has happened. 

[0026] Figure 2 is a representation of the flow of mes- 
sages between two communicating programs in a mes- 
sage queuing network in the simple example of one-to- 
one communication. The two programs 10.20 send 
messages to each other via queues 30.40 under the 
control of respective queue managers 50,60. The first 
program 10 puts messages onto the second program's 
queue 30 without a dedicated logical connection having 
to be established between the programs (this message 
flow is represented in Figure 2 by arrows f1. f2. fS and 
f4). The queue managers 50.60 ensure that the mes- 
sages are moved across the network, such that the pro- 
grams themselves are shielded from network variations 
and complexities. This is represented in Figure 2 by net- 
work link 70. All of the work involved in maintaining mes- 
sage queues, in handling network failures and restarts, 
and in moving messages around the network, can be 
handled by the queue managers. Program 20 subse- 
quently takes the messages from the queue 30 to proc- 
ess them, when it is ready rather than when the sending 
program 1 0 chooses. Any changes made to recoverable 
resources by the transfer cf messages and subsequent 
processing are recorded in recovery logs 80,90 for use 
in the event of a subsequent failure. 
[0027] As represented in Figure 3, queue managers 
100 may store messages onto a number of different 
queues. If the messages are eventually to be processed 
by kx:al application programs then the queue manager 
stores them on local destination queues 110; and if the 
messages are eventually to be processed by a remote 
applicatk>n. then the queue manager stor s them in spe- 
cial local queues known as transmission queues 120. 
Transmission queues containing messages t b sent 
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to queues belonging to rennote queu managers nabte 
themov ment of messages t remote queues to be car- 
ried out in stages between adjacent queue managers. 
This staging of messag transmission, which will b d - 
scribed in detail betow, is invisible to the application pro- 
grams involved in the communication. There may be a 
plurality of local destination queues and of transmission 
queues controlled by a particular queue manager, as wilt 
be explained below. 

[0028] The messages on a transmission queue are 
extended by the queue manager to include a transmis- 
sion queue header in addition to the application mes- 
sage (the data being transferred by an application). The 
transmission queue header is an architected descriptor 
containing the name of the destination queue and the 
message descriptor. Messages on destination queues 
include the application data and a message header 
specifying control intomnation. 
[0029] The transport relationship between two queue 
managers is known as a channel. The key elements de- 
fining a channel are the name of a transmission queue, 
information concerning the transport processes or pro- 
grams 130.150 which send or receive messages over 
the channel (these processes, which are part of the 
queue managers, are known as message channel 
agents - hereafter MCAs), and communications protocol 
and target system information for the destination to 
which messages on the transmission queue are to be 
sent. The association between a particular channel def- 
inition and the various data model entities involved in 
the message communk^tion is represented by broken 
lines in Figure 3. Each named channel is defined in both 
the sending and receiving nodes. The channel name is 
used in the transmissions between the sender and re- 
ceiver processes to identify the channel to the receiver 
or for a receiver to request that messages from a par- 
ticular channel be sent. Channel definition has some in- 
formation which is common for all environments and 
some which depends on the operating system environ- 
ment and underlying communicatons protocol to be 
used. 

[0030] The communication of messages between 
queue managers is carried out by MCAs working in pairs 
across specific channels: one sender 1 30 and one re- 
ceiver 150. A pair of MCA processes uses a transport 
connection 170 such as a VTAM APPC session or a 
TCP/IP connection as a transport layer. Message traffic 
in the opposite direction flows between a sender 160 
and a receiver 140 on a different channel, the channels 
being used effectively as uni-directional pipes between 
nodes. There are four types of MCAs: 

Sender - which takes messages from a transmis- 
sion queue and sends them to a Re- 
ceiver or Requester; 

Receiver - which receiv s messages and queues 
them; 

Requester- which s nds a single messag to cause 



a Sender r S rver to b started re- 
motely; 

Server - which is started by a message from a 
requ ster, and then becomes a Sender. 

5 

[0031] An MCA 1 30 dequeues messages from trans- 
misskxi queues and transmits them over the transport 
connectbn 170. The receiving MCA 150 queues the 
messages to the destinatkMi queues 180 named in the 
10 message header. These two units of work, dequeue and 
enqueue, are performed such that any failure at any 
point in the protocol can be detected and rectified so 
that each message is delivered once and once only In 
the case where the destinatksn queue is more than one 
IS hop from the original transmisskxi queue, the receiving 
MCA will queue the message on another transmisskxi 
queue for the next hop. This provdes a safe store and. 
in the event that the next connection is unavailable, the 
necessary asynchronism to allow this first stage of 
20 transmisskxi to still be carried out. The message format 
and the safe movement protocol are transport layer in- 
dependent so that MCAs can support different transport 
protocols on different channels. The protocols used by 
the MCAs are described betow. 
2S [0032] A channel may be started in a number of dif- 
ferent ways: 

1 . a terminal operator may issue a START CHAN- 
NEL command; 
30 2. the channel can be triggered, a Sender MCA be- 
ing started automatrcally by a queue manager when 
a message arrives on the transmissk>n queue; or 
3. by a network request • the communications trans- 
port being configured to automatically start an MCA 
3S when a request from the network is received. Re- 
ceiver, Server and Sender channels could be con- 
figured this way. 

[0033] Before any messages or data can flow down a 

40 channel, the two MCAs which are to use it must first ne- 
gotiate the way in which they are going to communicate. 
Thus, channel initialisation involves negotiation of cer- 
tain protocol parameters, such as which communication 
partner is going to do any needed conversion of control 

4S and message header data. Two MCAs may be running 
on systems using two different data formats. For exam- 
ple, one may be using ASCII and the other EBCDIC. 
One may be encoding numbers left to right, the other 
right to left. The control information and message head- 

so er data must be converted from the sender's represen- 
tation to the receiver's. Data conversion over channels 
applies only, to control information (such as destination 
queue name, control field Lengths, and the like): no ap- 
plication data conversion is performed by MCAs, since 

ss MCAs do not need to interact with the application data 
in a message when they transmit It. 
[0034] The method of delivering messages between 
applicatk>nsondiff r nt computer systems involves the 
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foltowing steps, described with r ferenc to Figures 4 
and 5: 

[0035] An application sends a message to a target 
destination queue for processing by another application 
by issuing (200) an MOPUT command. Th local queue 
manager reads the destination queue name specified 
by the application in the message's header and deter- 
mines (21 0) where to put the message. If the destination 
queue is a local queue then the local queue manager 
puts (220) the message into that local queue. The unit 
of work including the operation of putting the message 
to a queue must be committed before the message is 
available to other applicatbns. An application serving 
that local queue can then asynchronously issue 
MQGET (230) to take the message from the queue for 
processing. The MQPUT and MQGET operatk)ns are 
within two separate units of work. 
[0036] If the destination queue is not the responsibility 
of the toca\ queue manager, then the tocal queue man- 
ager puts the message onto a local transmission queue 
(240), for transfer to another queue manager There 
may be a plurality of transmission queues defined for 
each queue manager, but a one-to-one correspondence 
between transmission queues and remote destination 
queues is not necessary. All messages that are to be 
passed between two adjacent queue managers (that is, 
alt messages to be sent from a first queue manager 
which have a common nearest neighbour queue man- 
ager in the direction of their respective target destination 
queue managers) can be put in the same transmission 
queue. It is equally possible to have a number of trans- 
mission queues for traffic going to the same next node. 
A maximum batch size is specified (for example 50 mes- 
sages) to limit the number of messages which will have 
to be resent in the event of a failure. The unit of work 
300 which puts the message to the transmission queue 
must be committed before the message is available to 
other processes. 

[0037] The kx:al queue manager (or an end user) 
starts a serider MCA to transmit messages to the next 
queue manager. The sender MCA then gets messages 
(250) (Issues MQGET) from a transmission queue 
owned by this queue manager and transmits them as a 
batch to the next queue manager on the way to the des- 
tination queue manager or queue managers. Each mes- 
sage is either transmitted in one transmission or as a 
plurality of transmissbn segments in a plurality of trans- 
missions if the messages are too large for the transport 
connection to send in one go (e.g. a message might be 
4 Megabytes in size and the maximum transfer size 32 
kik)bytes). The steps of getting and transmitting mes- 
sages is performed within a syncpoint -manager-control- 
led unit of work 330. which is held in-doubt by the sender 
at this stage. Log records are written specifying the in- 
doubt state of the resource updates. The batch has a 
request for confirmatk>n of receipt of the batch attached 
to It: this is implemented by the last messag (or the last 
transmission segment of the last message) of the batch 



having a Request.Confimi control flag set in its trans- 
mission s gment header. 

[0038] Each message has a message sequence 
number associat d with it - one of a monotonicalty in- 

s creasing sequence of numbers, uniqu ly assign d to a 
single application message on a channel. Message se- 
quence numbers are used to resynchronise between 
sender and receiver in the event of a link failure or pro- 
gram failure. The highest message sequence number 

10 in the batch is taken as the logical unit of work identifier 
(LUWID) - a unique value defining a batch of messages 
on a channel which are under control of a syncpoint 
manager. 

[0039] The receiver MCA receives (260) the messag- 
es es and the receiver queue manager determines (210) 
where each message is to be sent (as the sending 
queue manager program did previously). The receiver 
queue manager puts the messages (using MQPUT) 
within a syncpoint-manager-controlled unit of work 360 
so to queues bete)nging to the receiving computer system's 
queue manager, which may be the actual application- 
specified destination queue for a particular message or 
may be a related transmission queue for the next hop 
towards the target system. 

[0040] Either all of the messages in the batch of mes- 
sages transferred by MCAs are successfully received 
and queued by the receiving queue manager or the 
batch is rejected as a whoie and not safe stored at the 
receiver (the unit of work is rolled back). If the batch is 

30 successfully received and queued then the receiver 
sends an acknowledgement of receipt and storage (a 
Status segment indicating "No error* is transmitted), 
having logged the LUWID and committed the batch of 
messages together as an atomic action. On receipt of 

35 the positive acknowledgement the sender also commits 
the batch of messages using the LUWID, this commit of 
the MQGET operatbn deleting the messages from the 
transmission queue. The next batch can then be started. 
If no messages are left on the transmission queue (and 

40 a preset time interval has expired) or a request to ck>se 
the channel has been received, then the connectk>n can 
be terminated. 

[0041] If the batch is rejected, an acknowledgement 
of rejection (a Status segment indicating Error - which 

4S may include details of the error) is transmitted to the 
sender which then rolls back its in-doubt messages onto 
the transmission queue ready for retry, and terminates 
the channel, if a batch of messages is rolled back, the 
sequence number or LUWID must also be rolled back, 

50 to the value of the last successfully committed batch. If 
no confirmation is received, due to transport or commu- 
nication-partner failure, then the channel is terminated 
by the sender and the receiver MCA's unit of work is 
rolled back. If the sender has not yet sent a confirm re- 

ss quest then the sender MCA should also roll back. If it 
has sent a confirm request then its log records and those 
of the receiver program must be examined to determin 
whether it shoM be committed or rolled back. The 
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MCAs automaticalty pert rm the determination of 
whether the first unit f work should be committed or 
roll d back (unless contact cann t be reestablished in 
which case the p rator may take the decision). F llow- 
tng a r llback, the sending MCA may try to re-establish 
a channel and resynchronise with the sending MCA in 
order to resend the failed batch. 
[0042] Channel resynchronisation is achieved during 
channel initialisatkxi. The sender MCA retrieves from Its 
log the in-doubt LUWID. or message sequence number 
of the last message sent for which a confinnation was 
also sent. The receiving MCA will check his logged LU- 
WIDs or sequence numbers to determine whether he is 
in sync with the sender. As a result of the comparison, 
he will confirm or reject the resynchronisation request 
by returning an appropriate Status segment, containing 
the LUWID or sequence number of the last successfully 
committed message or batch of messages at his end. If 
this value matches the sender's, the sender may conrvnit 
the previously sent messages, and commence sending 
the next one. If the receiver's value matches the previ- 
ous LUWID or sequence number, the sender rolls back 
and resends the prevbus message or batch. 
[0043] The MCAs thus use a syncpoint manager to 
control each batch as a logical unit of work. The unit of 
work including the MQGET of the sender message 
queue manager and the unit of work including the 
MQPUT of the receiver message queue manager are 
logically linked in that both are hekj in doubt until the 
receiver is ready to connmit. messages being conrvnitted 
at the receiving end before deleting them at the sending 
end using a single-phase commit protocol. Two phase 
commit is not required as the sender acts as a commit 
coordinator. Any system failure that occurs before the 
end of the batch, either at the sender or receiver, may 
require the unit of work to be backed out during a resyn- 
chronisation phase. 

[0044] This single-phase commit using logical linkage 
of units cf work on different systems avoids the problem 
of a two phase commit needing to synchronise (kxk) all 
participating resources in a distributed unit of work. In 
the present invention, resource managers do not actu- 
ally have to synchronise with each other. A limited period 
of inconsistency between resources as viewed by appli- 
cations is accepted, but final consistency is assured 
since atomic transaction processing is assured. 
[0045] To complete the assured delivery of messag- 
es, the target application which sen^ices the destination 
queue can issue MQGET to get messages from the 
queue as part of a unit of work 390 under the control of 
its local syncpoint manager, to allow rollback of the mes- 
sage to the queue in case of appltcatkxi failure or com- 
mit of a successfully processed message to delete it. 



Claims 

1. A method of inter-program c mmunication in a 



in response to unsuccessful receipt of the mes- 
sages, rolling back the second unit of work, 
transmitting to the sender program a negative 
confirmation of receipt, and In response to said 
negative confirmation backing out the first unit 
of work. 

2. A method according to claim 1 wherein said sender 
and receiver programs are located on adjacent 
nodes within a network, and wherein messages, 

35 which may be destined for different destination 
nodes, are transmitted between adjacent nodes on 
the way to their respective destination nodes as a 
batch of messages within a unit of work, the units 
of work incorporating said sending and receiving 

40 operations being held tn-doubt until the end of the 
batch. 

3. A method according to claim 2 wherein the last mes- 
sage in a batch is transmitted together with a re- 

4S quest for commitment of and for confirmation of re- 
ceipt of the batch, the commitment of said second 
unit of work and the transmission of said positive or 
negative confirmatksn being in response to said re- 
quest. 

so 

4. A method according to any one of claims 1 to 3 
wherein log records are written to record the in- 
doubt status of said units of work for use in recovery 
processing following a failure during the processing 

ss of said units of work, the log records being read dur- 
ing recovery processing to determine which units of 
work should be committed and which should be 
backed out. 



transaction-oriented data processing network 
wherein as nder program is r sponsible for send- 
ing messag s from a first nod f the network and 
a receiver program is r sponsible for rec ivingmes- 

5 sages at a s cond node of the network, m ssages 
to be transmitted between the two nodes being sent 
by the sender program within a first syncpoint-man- 
ager-controlled unit of work and being received by 
the receiver program within a second syrtcpoint- 

10 manager-controlled unit of work such that the send- 
ing and receiving operations are heki in-doubt. i.e. 
uncommitted, until resolution of the first and second 
units of work, respectively, characterised in that the 
first and second units of work are logically linked so 
that commit processing at resolution of the units of 
work comprises either 

in response to successful receipt of the mes- 
sages by the receiver program, committing sakJ 
^ second unit of work, transmitting to the sender 

program a positive confirmation of receipt, and 
in response to the positive confirmation com- 
mitting the first unit of work; or 

25 
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5. A method of inter-program communication acc rd- 
ing to any one f the preceding claims, which im- 
plements messaging and queuing for communica- 
tion between application programs, the application 
programs sending messages to messag queues s 
from where receiver application programs can 
asynchronously take the messages for processing 

or forwarding on. 

6. A method according to claim 5. wherein communi- io 
cation between application programs running on 
different computer systems of the network compris- 
es at least the following steps: 

a first applicatbn program issuing a put mes- ib 
sage instruction under control of a synchpoint 
manager in the sending computer system, for 
sending a message to a message queue; 

sender and receiver transmissk>n programs so 
transferring messages between the computer 
systems, as two k>gicalty linked units of work, 
using synchpoint managers In both the sending 
and receiving computer systems; and 

2S 

a second application program issuing a get 
message instruction under control of a synch- 
point manager in the receiving computer sys- 
tem, for taking the message from the queue; 

30 

wherein the units of work of put message, trans- 
fer and get message are each held in-doubt un- 
til resolution of the respective unit of work. 

7. A method according to claim 1 , wherein a message 3S 
to be delivered is sent to a queue from a sending 
application program at a first computer and is then 
asynchronously taken from the queue to be proc- 
essed by a receiving application program, charac- 
terised in that: 40 

each step of sending a message to a Queue or 
taking a message from a queue is carried out 
under the control of a message queue manager 
program, located at a computer in the network; 4S 



which messag s may be destined for different 
destination message queue manager pro- 
grams, ar transmissible to sad next message 
queue manager as one or mor batches of 
messages within syncpoint-manager-contr t- 
led units of work. 

8. A data processing system including a messaging 
manager for inter-program communication across 
a network of data processing systems, the messag- 
ing manager including sender and receiver pro- 
grams for transferring messages between adjacent 
messaging managers in the network in accordance 
with the following transfer protocol: 

a sender progrEmn of a frrst messaging manager 
sending one or more messages within a first 
syncpoint-manager-controlled unit of work; 

a receiver program in a second messaging 
manager receiving sa\6 messages within a sec- 
ond syncpoint-manager-controtled unit of work; 

the sending and receiving operations being 
hekJ in-doub. i.e. uncommitted, until resolution 
of the first and second units of work, respec- 
tively; and 

characterized in that the first and second units of 
work being logically linked so that commit process- 
ing at resolution of the first and second units of work 
comprises either 

(i) in response to successful receipt of the mes- 
sages by the receiver program, committing said 
second unit of work, transmitting to the sender 
program a positive confirmation of receipt, and 
in response to the positive confirmation com- 
mitting the first unit of work; or 

(ii) in response to unsuccessful receipt of the 
messages, rolling back the second unit of work, 
transmitting to the sender program a negative 
confirmation of receipt, and in response to said 
negative confirmation backing out the first unit 
of work. 



messages to be delivered to a local applk:ation 
program are put on a local queue serviced by 
the local application program; whereas 

so 

messages to be delivered to remote applcatton 
programs on remote computers are put on local 
transmission queues for transmission, respec- 
tively for each transmission queue, to the next 
message queue rrianager program on the way ss 
to the resp ctive d stinatksn remote message 
queue manager programs, wherein all messag- 
es put on a particular transmissbn queue. 



A data processing system according to claim 8, 
wherein the messaging manager is adapted for 
message queuing inter-program communication 
across a heterogeneous network of data process- 
ing systems, the messaging manager including an 
application programming interface by which appli- 
cations attach to the messaging manager and pro- 
viding queuing services enabling application pro- 
grams to put messages onto message queues for 
asynchronous retrieval by other application pro- 
grams. 
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Pat ntanspruehe 

1. Ein Verfahren der tnterprogramm-Kommunikation 
in einem transaktionsorientierten Datenverarbei- 
tungsnetzwerk, wobei ein Senderprogramm verant- 
wortlich ist, Nachrichten von einem ersten Knolen 
des Netzwerks zu senden, und ein Empfangerpro- 
grannm verantwortlich ist, Nachrichten in einem 
zweiten Knoten des Netzwerks zu empfangen, 
Nachrichten zwischen den beiden Knoten zu Qber- 
tragen, die von dem Senderprogramm innerhalb ei- 
ner ersten. vom Synchronisierungspunkt-Manager 
gesteuerten Arbeitseinheit gesendet und von dem 
Empfangerprogramm innerhalb einer zweiten. vom 
Synchronisierungspunkt*Manager gesteuerten Ar- 

* beitseinhert empfangen wurden. so da3 die Sende- 
und Empfangsoperationen bis zur Auftosung der er- 
sten bzw. der zweiten Arbeitseinheit in Zweif el ge- 
zogen werden. d.h. nicht festgeschrieben werden. 
dadurch gekennzeichnet, daB die ersten und zwei- 
ten Arbeitsetnheiten logisch verknupft sind, so daB 
die Festschreibverarbeitung in der Aufiosung der 
Arbeitseinheiten entweder enthalt: 

als Reaktk>n auf den erfofgreichen Empfang 
der Nachrichten von dem Empfangerpro- 
gramm. die zweite Arbeitseinheit festzuschrei- 
ben, an das Senderprogramm eine positive 
Empfangsbestatigung zu senden, und als Re- 
aktton auf die positive Bestatlgung die erste Ar- 
beitseinheit festzuschreiben; Oder urn 

als Reaktlon auf den nicht erfotgreichen Emp- 
fang der Nachrichten, die zweite ArbeKseinheit 
zu wiederhoien, dem Senderprogramm eine 
negative Empfangsbestatigung zu senden. und 
als Reaktion auf die negative Bestatigung, die 
erste Arbeitseinheit zuruckzusetzen. 

2. Ein Verfahren gemal3 Anspruch 1 . wobei die Sen- 
der- und Empfangerprogramme in benachbarten 
Knoten in einem Netzwerk untergebracht sind, und 
wobei Nachrichten, die f ur verschiedene Zielknoten 
bestimmt sein konnen, zwischen den benachbarten 
Knoten uber ihre jeweiligen Zielknoten als ein Sta- 
pel von Nachrichten innerhalb einer Arbeitseinheit 
Obertragen werden. wobei die Arbeitseinheiten. 
welche die Sende- und Empfangsoperationen ent- 
halten. bis zum Ends des Stapels in Zweifel gezo- 
gen werden. 

3. Ein Verfahren gemaB Anspruch 2, wobei die letzte 
Nachricht in einem Stapel zusammen mit einer An- 
forderung Obertragen wird, den Empfang des Sta- 
pels festzuschreiben und zu bestatigen, wobei das 
Festschreiben der zweiten Arbeitseinheit und die 
Ubertragung der positiven und negativen Bestati- 
gung eine Reaktlon auf dies Anforderung ist. 



4. Ein Verfahren gemaB einem der Anspruche 1 bis 3= 
wob i die Protokollaufzeichnungen geschrieben 
werden. um den zweifelhaften Status der Arbeits- 
einheit n aufzuzeichnen, um dies fQr die Wieder- 

5 herstellungsverarbeitung im AnschluB an einen 
Ausfall wahrend der Verarbeitung der Arbeitsein- 
heiten zu benutzen, wobei die Protokollaufzeich- 
nungen wahrend der Wiederherstellungsverarbei- 
tung gelesen werden. um zu bestimmen, welche Ar- 

10 beitseinheiten festgeschrieben und welche zuruck- 
gesetzt werden sollten. 

5. Ein Verfahren der Inlerprogramm-Kommunikatkxi 
gemaB einem der vorhergehenden Anspruche, wei- 

IS che die Nachrichtenerstellung und die Warte- 
schlangenbildung zur Kommunikation zwischen 
den Anwendungsprogrammen implementieren, 
wobei die Anwendungsprogramme Nachrichten an 
Nachrichten-Warteschlangen senden, aus denen 
20 die Empfangeranwendungsprogramme Nachrich- 
ten asynchron herausnehmen konnen, um diese zu 
verarberten oder zu senden. 

6. Ein Verfahren gemaB Anspruch 5» wobei die Kom- 
2S munikation zwischen den Anwendungsprogram- 
men, die in verschiedenen Computersystemen des 
Netzwerks laufen, wenigstens die folgenden Schrit- 
te enthalt: 

30 ein erstes Anwendungsprogramm, das einen 

Put-Nachrichtenbefehl unter der Kontrolle ei- 
nes SynchronisierungspunktManagers in das 
sendende Computersystem eingibt, um eine 
Nachrrcht an eine Nachrichten-Warteschlange 
3S ZU senden; 

Sender- und Empfangerubertragungsprogram- 
me, die Nachrichten zwischen den Computer- 
systemen wie zwei logisch verknupfte Arbeits- 
^0 einheiten mittels Synchronisierungspunkt-Ma- 

nagem sowohl an die sendenden als auch die 
empfangenden Computersysteme Obertragen; 
und 

45 ein zweites Anwendungsprogramm, das einen 

Get-Nachrichtenbefehl unter der Steuerung ei- 
nes Synchronisierungspunkt-Managers an das 
empfangende Computersystem ausgibt, um 
die Nachricht aus der Warteschlange zu neh- 
so men; 

wobei die Arbeitseinheiten der Put-Nachricht, 
der Transfer- und Get-Nachricht jeweils bis zur 
Aufiosung der jeweiligen Arbeitseinheit ange- 
ss zweifelt werden. 

7. Ein Verfahren gemaB Anspruch 1 . wobei eine aus- 
zuhandigende Nachricht von einem sendenden An- 
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wendungsprogramm in einem ersten Comput r an 
eine Warteschlange gesendet wird und dann asyn- 
chron von einem Empfangsanwendungsprogramm 
aus der zu verarb itenden Warteschlange h reus- 
genommen wird, wobei das Verfahren dadurch ge- 
kennzeichnet ist, dad 

jeder Schritt, um eine Nachricht an eine Warte- 
schlange zu senden Oder um eine Nachricht 
aus einer Warteschlange herauszunehmen, 
unter der Kontrolle eines Nachrichten-Warte- 
schlangen-Managerprogramms erfoigt, das in 
einem Computer im Netzwerk vorhanden ist; 

Nachrichten. die an ein lokales Anwendungs- 
programm zu liefem sind, in eine bkale Warte- 
schlange gelegt werden. die von dem lokalen 
Anwendungsprogramm bedient wird; wahrend 

Nachrichten. die an Femanwendungsprogram- 
me in entfernt stehenden Computem zu tief em 
sind. in bkale Ubertragungswarteschlangen fur 
die Ubertragung gelegt werden bzw. fur jede 
Ubertragungswarteschlange an das nachste 
Nachrichten-W^rteschlangen-Managerpro- 
gramm uber das jeweillge enttemt stehende 
Ziel-Nachrichten-Warteschlangen-Manager- 
programm, wobei alie Nachrichten. die in eine 
bestimmte Ubertragungswarteschlange gelegt 
werden. deren Nachrichten fur verschiedene 
Ziel-Nachrichten-Warteschlangen-Manager- 
programme bestimmt sind. an das nachste 
Nachrichten-Warteschtangen-Managerpro- 
gramm als ein Stapel Nachrichten in einer von 
einem Synchronislerungspunkt-Manager ge- 
steuerten Arbeitseinheit ubertragbar sind. 

Ein Datenverarbeitungssystem, das einen Nach- 
rtchtenerstellungsmanager zur Interprogramm- 
Kommunikation innerhalb eines Netzwerks mit Da- 
tenverarbeitungssystemen hat, wobei der Nach- 
richtenerstellungsmanager Sender- und Empfan- 
gerprogramme enthalt, um Nachrichten zwischen 
benachbarten Nachrichtenerstellungsmanagern in- 
nerhalb des Netzwerks gemalB dem folgenden 
Ubertragungsprotokoll zu Obertragen: 

ein Senderprogramm mit einem ersten Nach- 
richtenerstellungsmanager, der eine Oder meh- 
rere Nachrichten innerhalb einer ersten, von ei- 
nem Synchronisierungspunkt-Manager ge- 
steuerten Arbeitseinheit sendet; 

ein Empfangerprogramm in einem zweiten 
Nachrichtenerstellungsmanager, der Nachrich- 
ten innerhalb einer zweiten. von inem Syn- 
chronisierungspunkt-Manager gesteuerten Ar- 
beitseinheit empfangt; 



wobei die Sende- und Empfangsoperationen 
bis zur Auflosung der rsten bzw. der zweiten 
Arbeitseinheit angezweifelt werden. d.h. nicht 
f stgeschrleben werd n; und 

5 

dadurch gekennzeichnet, daf) die ersten und zwei- 
ten Arbeitseinheiten bgisch verknupft sind. so da3 
die Festschreibverart>eitung in der Auflosung der 
Arbeitseinheiten entweder enthalt: 

10 

(i) als Reaktion auf den erfolgrebhen Empfang 
der Nachrichten von dem Empfangerpro- 
gramm, die zweite Arbeitseinheit festzuschrei- 
ben. an das Senderprogramm eine positive 

^5 Empfangsbestatigung zu senden. und als Re- 

aktion auf die positive Bestatigung die erste Ar- 
beitseinheit festzuschreiben; oder um 

(ii) als Reaktion auf den nicht erfolgrelchen 
^ Empfang der Nachrichten, die zweite Arbeits- 
einheit zu wiederhoien. dem Senderprogramm 
eine negative Empfangsbestatigung zu sen- 
den, und als Reaktion auf die negative Besta- 
tigung, die erste Arbeitseinheit zuruckzuset- 

2S zen. 

9. Ein Datenverarbeitungssystem gemaO Anspruch 8, 
wobei der Nachrichtenerstellungsmanager ange- 
paBt ist. um Nachrichten in der Interprogramm- 

^ Kommunikation innerhalb eines heterogenen Netz- 
werks von Datenverarbeitungssystemen in Warte- 
schlangen einzureihen, und der Nachrichtenerstel- 
lungsmanager eine Anwendungsprogrammschnitt- 
stelle enthalt, uber die Anwendungen mit dem 

3S Nachrichtenerstellungsmanager verbunden wer- 
den und Warteschlangenbildungs-Sen/ices bereit- 
gestellt werden. mit denen Anwendungsprogram- 
me Nachrichten in Nachrichten-Warteschlangen 
zwecks asynchronem Abruf durch andere Anwen- 

^ dungsprogramme legen konnen. 



Revendications 

45 1. Proc6d6 de communications entre des program- 
mes dans un r^seau de traitement de donndes 
orients transactbns dans lequel un programme 
^metteur est responsable de remission de messa- 
ges d partir d'un premier noeud du rdseau et un pro- 
so gramme r^cepteur est responsable de la reception 
des messages au niveau d'un second noeud du rd- 
seau, les messages devant dtre transmis entre les 
deux noeuds 6tant 6m\s par le programme dmetteur 
k I'intdrieur d'une premiere unit4 de tdche comman- 
ds dde par un gestionnaire de point de synch ronisatkxi 
et dtant re^us par le programme r^cepteur d I'intd- 
rieur d'une seconde unitd de tdche commandde par 
un gesti nnaire de point de synchronisation de sor- 
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te que les operations d'dmission et de reception 
soient maint nues dans Tincertitude, c'est-d-dire 
non ngagdes, jusqu'd la resolution des premiere 
et seconde unites de tdche. respectivent nt, carac- 
t^risd n ce que les premier et seconde unites de 
tdche sont lides logiquement de sorte que I'enga- 
gement du traitement ^ la resolution des unites de 
tdche comprend soit : 

en rdponse k la reception correcte des messa- 
ges par le programme r^cepteur, {'engagement 
de ladite seconde unite de tSche, la transmis- 
sion vers le programme dmetteur d'une confir- 
mation de reception positive, et en reponse k 
la confirmation positive ^engagement de la pre- 
miere unite de tdche, ou 

en reponse k une reception incorrecte des 
messages, le renvoi de la seconde unite de td- 
Che, en transmettant au programme emetteur 
une confirmation de reception negative, et en 
reponse k la confirmation negative la restitution 
de la premiere unite de tdche. 

2. Precede selon la revendlcation 1, dans lequel les- 
dits programmes emetteur et recepteur sont locali- 
ses sur des noeuds adjacents k I'interieur d'un re- 
seau, et dans lequel des messages, qui peuvent 
dtre destines k difterents noeuds de destination, 
sont transmis entre des noeuds adjacents en route 
vers leurs noeuds de destination respectifs sous 
forme d'un lot de messages k I'interieur d'une unite 
de tdche, les unites de tdche incorporant lesdites 
operations d'emissbn et de reception qui sont 
maintenues dans I'incertltude jusqu'd la fin du tot, 

3. Precede selon la revendlcation 2, dans lequel le 
dernier message d'un tot est transmis en meme 
temps qu'une demands d'engagement et pour con- 
finfnatton de la reception du lot, {'engagement de la- 
dite seconde unite de tdche et la transmission de 
ladite confirmation positive ou negative se faisant 
en reponse k ladite demande. 

4. Precede selon I'une quelconque des revendications 
Ids, dans lequel des enregistrements de journali- 
sation sont ecrits pour enregistrer la situation d'in- 
certitude desdites unites de tdche en vue d'une uti- 
lisation dans le traitement de recuperation qui suit 
une del alliance durant le traitement desdites unites 
de tdche, les enregistrements de journalisation 
etant lus pendant le traitement de recuperatton afin 
de determiner quelles unites de tdche devraient 
etre engagdes et lesquelies devraient dtre resti- 
tuees. 

5. Precede de communications entre des program- 
mes selon Tune quelconque des rev ndications 



precedentes. qui met en oeuvre une messageri et 
une mise n file d'attente des communications entre 
des programm s d'application. les programmes 
d'applrcation emettant des messages vers des files 
s d'attente de messag s d partir desqueltes des pro- 
grammes d'application du recepteur peuvent preie- 
ver les messages de fa^on asynchrone en vue d'un 
traitement ou pour les propager. 

10 6. Precede selon la revendication 5. dans lequel les 
communicattons entre les programmes d'applica- 
tien s'executant sur des systdmes informatiques dif- 
terents du reseau comprennent au motns les etapes 
suivantes : 

IS 

un premier programme d'appiication qui emet 
une instruction de placement de message sous 
la commands d'un gestionnaire de point de 
synchronisation dans les systdmes informati- 
20 ques emetteurs. en vue d'emettre un message 

vers une file d'attente de messages. 



des programmes de transmission de t'emetteur 
et du recepteur qui transfdrent des messages 
2S entre les systdmes informatiques. sous iorme 

de deux unites de tdche lides logiquement, en 
utiiisant des gestionnaires de points de syn- 
chronisation dans les deux systdmes informa- 
tiques d'emission et de reception, et 

30 

un second programme d'appiication qui emet 
une instructton de prise de message sous la 
comn^nde d'un gestionnaire de point de syn- 
chronisatton dans le systdme informatique de 
3S rdceptton. afin de prdlever le message de la file 

d'attente, 

dans lequel les unites de tache des instructions 
de placement de message, de transfert et de 
^ prise de message sont chacune maintenues 

dans ^incertitude jusqu'd la resolution de t'unite 
de tdche respective. 

7. Procddd selon la revendication 1. dans lequel un 
message devant etre deiivre est emis vers une file 
d'attente d partir d'un programme d'appiication 
emetteur au niveau d'un premier ordinateur et est 
ensuite prdievd de fa9on asynchrone de la file d'at- 
tente devant dtre traitee par un programme d'appli- 
so cation de reception, caracterise en ce que : 

chaque etape consistant d envoyer un messa- 
ge vers una file d'attente ou d prdlever un mes- 
sage d'une file d'attente est executee sous la 
ss commande d'un programme de gestionnaire de 

file d'attente de messages, localise au niveau 
d'un ordinateur du reseau. 
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les messages d vant dtr d^livrds k un pro 
gramme d'application local sont places sur une 
file d'attente locale desservie par le pr gramme 
d'applicatioT) local, alors que 

5 

des messages devant §tre d6livr6s k des pro- 
grammes d'application distants sur des ordina- 
teurs k distance sont places sur des files d*at* 
tente de transmission locales en vue d'une 
transmission, respectivement pour chaque file io 
d'attente de transmission, vers le programme 
de gestionnaire de file d'attente de messages 
suivant sur I'ttin^raire vers les programmes de 
gestionnaire de file d'attente de messages dis- 
tants de destination respectifs, dans lequel 
tous les messages places sur une file d'attente 
de transmission particuli^re, lesquels messa* 
ges peuvent Stre destines h des programmes 
de gesttonnaires de file d'attente de messages 
de destination diffdrents, peuvent dtre transmis 
audit gestionnaire de file d'attente de messa- 
ges suivant sous forme d'un ou plusieurs lots 
de messages k I'int^rieur d'unit6s de tSche 
commandoes par un gestionnaire de point de 
synchronisation. 

Systems de traitement de donnees comprenant un 
gestionnaire de messagerie destine ci des commu- 
nications entre les programmes sur un rOseau de 
syst^mes de traitement de donndes. le gestionnaire so 
de messagerie comprenant des programmes dmet- 
teurs et r^epteurs destines k transfdrer des mes- 
sages entre des gestionnaires de messageries ad- 
jacents du rdseau conformOment au protocole de 
transfert suivant : 3S 



(i) en rOponse k la reception correcte des mes- 
sages par le programme r6cepteur, I'engage- 
ment de ladite seconde unitd de Xkch . en 
transmettant au programme Ometteur un con- 
firmation de reception positive, et en ngageant 
en rdponse k la confirmation positive la premie- 
re unitO de tdche, ou 

(ii) en rdponse ci la reception incorrecte des 
messages, le renvoi en retour de la seconde 
unitO de tdche. en transmettant au programme 
dmetteur une confirmation de r^eption nega- 
tive, et en restituant en rOponse k ladite confir- 
mation negative la premiere unitd de t^che. 

9. Syst6me de traitement de donn6es selon la reven- 
dication 6. dans lequel le gestionnaire de message- 
ries est con9u pour des communications entre des 
programmes de mise en file d'attente de messages 
sur un rdseau hdtdrogdne de systdmes de traite- 
ment de donnees, le gestionnaire de messageries 
comprenant une interface de programnr^tion d'ap- 
plication grdce k taquelle des applications se ratta- 
chent au gestionnaire de messageries et foumis- 
sant des sen^ices de mise en file d'attente permet- 
tant k des programmes d'applicatbn de placer des 
messages sur les files d'attente de messages en 
vue d'une recuperation asynchrone par d'autres 
programmes d'application. 



un programme emetteur d'un premier gestion- 
naire de messageries emettant un ou plusieurs 
messages k I'interieur d'une premiere unite de 
tdche commandee par un gestionnaire de point 40 
de synchronisation, 

un programme recepteur dans un second ges- 
tionnaire de messageries recevant lesdits mes- 
sages k I'interieur d'une seconde unite de tSche 
commandee par un gestionnaire de point de 
synchronisation, 

les operations d'emission et de reception etant 
maintenues dans Tincertitude, c'est-^-dire non so 
engagees. jusqu'd la resolution des premiere 
et seconde unites de tdche. respectivement. et 

caracterise en ce que les premiere et seconde uni- 
tes de tSche sont Ii6es logiquement de fa^on k ce 55 
que I'engagement du traitement k la resolution des 
premiere et seconde unites de tdche comprend soit 
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